A Thread Debugger for Testing and Reproducing Concurrency Scenarios

Definitive testing of concurrency scenarios Execution sequence of multithreaded programs inherently nondeterministic Program behavior in different executions need not be the same Context switches, event ordering and synchronization are main reasons Mismatch between programming model and debugging model Capability to record, analyze and playback particular execution sequences Software pattern needed over which definitive replay can be done Software pattern BERT used for building concurrent software BERT is based on the Reactor pattern Reactor provides event de-multiplexing framework Events captured by the Reactor Event can be I/O completion, timer expiration or signal Concurrent software built using the BERT uses a user level thread library(Bthreads) Bthreads uses the many-to-one model Bthreads library provides capabilities for user specified context switching and locking the scheduler GNU debugger (GDB) extended to provide the capability to debug software written using the Bthreads library Capability to record events of interest provided within the thread library Capability to replay an execution sequence illustrated in the debugger 6 Background Challenges in debugging multithreaded programs Execution control interleaves between the threads Threads may voluntarily suspend and resume execution or they might do it as a result of events like signals Order of interleaving between threads partially determined by synchronization between the threads